圖片來源

這絕對是我在剛接觸 Web App 開發的時候就想知道的一張圖，圖片來源的整篇文章也很適合精讀，Staff Engineer 層級以下的面試應該蠻有用的(？) 各種 Web 開發大概都不脫這個套路，最多就是各個元件加深、加大、加快、加 HA、加 Cache...等等，我們 Demo 要做的 3-tier Web App，也只是這張圖的精簡版。以 Cloud Native 開發的角度來看，這張圖有個比較可惜的地方，就是沒有把 Public Cloud Provider (以下簡稱平台)提供的基礎建設標示出來。我們可以粗分為幾類：

1. 你大概不會想自己搞，會使用平台提供的： DNS、CDN、Load Balancer
2. 你大概會自己寫的： Web App Servers、各種 Services、各種 Jobs
3. 你大概會拿來用的第三方套件，可以自己 host ，也可以使用平台提供的，很大一部分是成本取向： Storages、Data Warehouse 、 Caching Services

前兩項在做技術棧決定的時候，除了各種內部的政治因素之外…大概爭議比較少。第一項各個平台提供和設定的方式都大同小異，第二項是自己團隊可以完全掌握的，比較麻煩的是第三項。

拿 SQL Database 來舉例，一般使用者可能很習慣使用 MySQL 或是 PostgreSQL 一類開源的資料庫，也很熟悉相關的 API 用法，但是在平台上的資料庫，可能因為開源協議、維運成本、本身的商業考量…等等，無法提供百分之百相容開源版本的 API。遇到這種情況，有幾種常見選擇

• 要嘛就是完全依賴平台提供的第三方元件，開發初期就在平台上，但這樣成本很高，想想你開發的時候，有幾個 RD 就開幾個 AWS EC2 instance，團隊成本一定會上升
• 另一種選擇就要使用各種中間件，像是 ORM ，讓開發時使用的第三方元件與平台提供的第三方元件能無縫接軌
• 還有一種選擇就是自己的第三方元件自己 own ，你開發時用 MariaDB 10.3 ，在平台上就自建 MariaDB 10.3 Cluster，。

理想很豐滿，現實很骨感…牽涉到相容性的問題時，往往都沒那麼簡單，第三方中間件很少能面面俱到，要自由度高，又要價錢低，還要用最少的薪水請到最有經驗的開發人員(幫 QQ)，除了壓榨工程師可能相對容易(？)以外，其他兩項很難同時滿足。

為什麼要花篇幅討論自由度， 絕對不是因為 Demo 還沒寫完要用廢話充版面， 我寫這個系列，有很大一部分是想紀錄自己遇到的坑，還有當初做某件事的時候，如果能早點知道什麼樣的知識的話就好了。因此，在這個系列文裡面，我都盡可能挑選技術生命週期比較長久，自由度與成本能夠平衡的技術棧，並且提到可能的替代品，讓讀者自行比較與選擇。

舉個例子來說

• 為什麼我們 Configuration Management 的工具是選 Ansible 而不是 Chef、Puppet？因為 Ansible 是 Python based 的，使用 Jinja2 Template ，而我們認為 Python 作為風行的膠水工具還有科學計算語言，在這裡使用 Python based 的技術棧，無論是安裝方式或是要自己魔改 source code ，可能都更為容易
• 為什麼我們 Kubernetes 的 Bootstrapping 是使用 Kubeadm ，而不是 Kops、Kubespray ，或是平台提供的 EKS、GKE、AKS ？因為 Kubeadm 可以在各種平台的 VM ，甚至自建的資料中心、VMWare 都可以做 Bootstrapping

必須說，還有許多這樣的例子。而技術棧的選擇，更多時候都是政治因素和成本考量，不是我們這種小小開發人員可以決定的。跟平台藕合性越高，就是用未來換現在，會被平台綁得越緊。好比說，利用 AWS API Gateway + Lambda 寫了一些服務，這些服務就很難搬到 GCP 或是本地的資料中心。我會覺得是自由度很低的技術棧選擇，但一個技術團隊的發展，沒有什麼是比無法帶來業務收入更大的罪惡(認真)，如果現在的技術選擇，能符合現在的業務發展，也未嘗不可？合理的技術債才能創造更多工程師的工作啊(默)，而不合理的技術債能創造更多的工作

至少在這系列文章，我會自由地、盡量地保持上述提到的自由度平衡，我認為這是更利於學習與了解 Cloud Native 相關技術的。

明天應該可以開始技術一點了吧，應該，吧，雖然只是寫一些 Yaml